docs/examples/restart-on-config-change/README.md (1)

16-34: Script no longer watches for multiple config changes after switching to SIGUSR1

With kill -SIGUSR1 $PID the llama-swap process keeps running, so the subsequent wait $PID blocks until the process eventually exits. That means:

• The first config change triggers a reload via SIGUSR1.
• Further changes are not detected because the loop doesn’t reach the next inotifywait until the process dies.

This is at odds with the description that the script “can be used to watch config.yaml for changes and send the SIGUSR1 signal … when it detects a change.”

Consider restructuring so the process is started once and the loop only waits on inotify + sends SIGUSR1 while the PID is alive, for example:

-while true; do
-    # Start the process again
-    ./llama-swap-linux-amd64 -config $1 -listen :1867 &
-    PID=$!
-    echo "Started llama-swap with PID $PID"
-
-    # Wait for modifications in the specified directory or file
-    inotifywait -e modify "$1"
-
-    # Check if process exists before sending signal
-    if kill -0 $PID 2>/dev/null; then
-        echo "Sending SIGUSR1 to $PID"
-        kill -SIGUSR1 $PID
-        wait $PID
-    else
-        echo "Process $PID no longer exists"
-    fi
-    sleep 1
-done
+# Start the process once
+./llama-swap-linux-amd64 -config "$1" -listen :1867 &
+PID=$!
+echo "Started llama-swap with PID $PID"
+
+while kill -0 "$PID" 2>/dev/null; do
+    # Wait for modifications in the specified file
+    inotifywait -e modify "$1"
+
+    if kill -0 "$PID" 2>/dev/null; then
+        echo "Sending SIGUSR1 to $PID"
+        kill -SIGUSR1 "$PID"
+    else
+        echo "Process $PID no longer exists"
+        break
+    fi
+done
+
+wait "$PID"

llama-swap.go (1)

88-119: Data race on srv.Handler during concurrent reload.

The srv.Handler field is accessed concurrently without synchronization:

• Write access: Lines 100 and 117 assign a new ProxyManager to srv.Handler
• Read access: The HTTP server reads srv.Handler.ServeHTTP() for each incoming request

In Go, unsynchronized concurrent read/write access to the same memory location constitutes a data race, even for pointer assignments. This can lead to undefined behavior, crashes, or serving requests with a partially-initialized handler.

Recommended solutions:

1. Wrap srv.Handler in a synchronized wrapper (preferred for minimal disruption):

// Add near top of main():
type SafeHandler struct {
    mu      sync.RWMutex
    handler http.Handler
}

func (sh *SafeHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    sh.mu.RLock()
    h := sh.handler
    sh.mu.RUnlock()
    h.ServeHTTP(w, r)
}

func (sh *SafeHandler) Set(h http.Handler) {
    sh.mu.Lock()
    sh.handler = h
    sh.mu.Unlock()
}

Then modify the server setup and reloadProxyManager:

-srv := &http.Server{
-    Addr: *listenStr,
-}
+safeHandler := &SafeHandler{}
+srv := &http.Server{
+    Addr:    *listenStr,
+    Handler: safeHandler,
+}

And in reloadProxyManager:

-    if currentPM, ok := srv.Handler.(*proxy.ProxyManager); ok {
+    if sh, ok := srv.Handler.(*SafeHandler); ok {
+        sh.mu.RLock()
+        currentPM, isPM := sh.handler.(*proxy.ProxyManager)
+        sh.mu.RUnlock()
+        if isPM {
             // ... reload logic ...
-            srv.Handler = newPM
+            sh.Set(newPM)
+        }
     } else {
         // ... initial load ...
-        srv.Handler = newPM
+        if sh, ok := srv.Handler.(*SafeHandler); ok {
+            sh.Set(newPM)
+        }
     }

2. Use atomic.Value for lock-free reads (alternative):

var handler atomic.Value  // stores http.Handler
srv.Handler = http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    handler.Load().(http.Handler).ServeHTTP(w, r)
})
// In reloadProxyManager: handler.Store(newPM)